1. Technical Field
The present invention relates to executing an enterprise application. More particularly, the present invention relates to executing an object-oriented enterprise application, which includes at least one method, which includes trigger or control points for attaching and running rules.
2. Description of Related Art
Recently, businesses, particularly large enterprises, have moved toward object-oriented programming as a means to make the implementation of their business applications more flexible and adaptable to business environment and business practice changes. While this is a step forward compared to previous art, many businesses are finding that it is necessary to go beyond conventional object-oriented programming to achieve the flexibility and adaptability they require.
One approach to this is to externalize the highly variable business decisions into business rules, which are described and manipulated by business experts instead of developers. Applications entitled “Method And Apparatus For General Integrity Rule Checking Point In An Application,” U.S. patent application No. 09/204,970, filed even date hereof, assigned to the same assignee; and “System and Method And Data Processing System For Specifying And Applying Rules To Classification-Based Decision Points In An Application System” U.S. patent application No. 09/204,970, filed even date hereof, assigned to the same assignee, are two examples of this approach.
In designing and constructing an application, developers face an analogous problem. They, too, would like to be able to add to or modify the application's behavior without having to change the code of the application, but with a technical rather than business intent. Two examples should suffice to demonstrate this. During the testing phases of development or when problems arise after an application has gone into production, it is often desirable to temporarily add functionality at specific points in the application's implementation object model. The functionality is added to check that particular technical invariants (the date and time of the last update of an object may not be earlier than an operation that it was before it) or constraints (a Person object may have no more than one spouse at any given point in time) imposed by the implementation object model are not being violated. The information can also be recorded internally to the application in a log for later analysis. Similarly, it often arises that it is desirable, particularly in “packaged” applications intended for use in multiple different enterprises, to be able to convert data between a form or forms that are convenient to the various end users and the form or forms used internally by the application.
The prior art cited above describes points of potential rule attachment (the “control points”) in business terms, not terms related to the application's implementation object model. Nonetheless, a business rules facility can sometimes be used for developers' technical, as opposed to business, purposes; the added or altered functionality is implemented using the same mechanism used to implement externalized business rules. But doing so has three distinct disadvantages. First, adding technical rules to the business rules can be confusing for the business experts; not all of the rules they see would then be business rules. This makes their work more difficult and error prone. Second, it requires that the application developers recast their technical problem in business terms to discover which, if any, existing business-oriented control points they can use to attach their technical rule. Third, the control points required to make the application flexible to business changes often do not necessarily occur where they need to for technical purposes. It is apparent, therefore, this approach is not adequately adapted for technical use by developers.
Another approach to this problem is to add the required new behavior to the system by using the well-known “Decorator,” “Strategy,” or “Template Method” patterns as taught by Erich Gamma, et al, “Design Patterns: Elements Of Reusable Object-Oriented Software By Gamma” Addison-Wesley Publishing Company, ISBN 0-201063361-6, pp. 175–179. Use of these techniques has the advantage for the developer of being tied directly to the application's implementation object model. For example, the Decorator pattern, in particular when used in a design that strictly separates object interfaces from object implementations, is often easy to use to cause a decorated object to exhibit arbitrary additional or modified behavior just before or just after any method of the decorated object. But all of these object-oriented coding patterns have the strong disadvantage that the added or altered functionality must be implemented by making programming changes, a more complex and time consuming process than is changing an externally defined rule.